utACK c8a3326

In general, this looks like a solid simplification and likely fixes the problem in the PR description. Can we add a test that triggers a reorg after fetch_tip_and_latest_blocks to confirm?

While reviewing, I noticed the chain-update logic is a bit convoluted, which makes this (and other bdk_electrum changes) tricky to follow:

• block_header_cache is keyed by height (not block hash), so it’s unclear how we’re ensuring the right header.
• The !valid block section updates block_header_cache on reorgs after fetch_tip_and_latest_blocks, meaning headers from different chains can co-exist. Anchors from batch_fetch_anchors may also not match the same chain.
• In chain_update, we use blockhashes from anchors to craft the CheckPoint update. Because inconsistencies are possible, we also pass in lastest_blocks, assuming reorgs aren’t deeper than CHAIN_SUFFIX_LENGTH.

I suggest we merge this PR ASAP (since it’s an important fix).

Then, in a follow-up PR, we could simplify the codebase:

1. Key block_header_cache by blockhash instead of height. Fetch by height through the CheckPoint chain.
2. Remove the !valid block section, since headers will always match the chain. Reorgs will naturally invalidate anchors and re-fetch them.
3. Let fetch_tip_and_latest_blocks() just fetch blocks. Move chain-update logic into chain_update(), updated to take heights_we_are_interested_in instead of anchors. Call chain_update() after batch_fetch_anchors.

This may slightly slow down bdk_electrum (extra header lookups via CheckPoint), but IO is the real bottleneck. Once the skip-list is in, CheckPoint lookups will be fast.

On second though... maybe we should only do bug fixes and focus effort in bdk_electrum_streaming?

Looks good.

Just a few nits in terms of documenting the test and unnecessary calls.

ACK fdec863